In the Third Generation Partnership Project (3GPP), specification is ongoing for home base stations in Wideband Code Division Multiple Access/Universal Terrestrial Radio Access Network (WCDMA/UTRAN) and in E-UTRAN (Evolved Universal Terrestrial Radio Access Network). E-UTRAN is the next generation of Radio Access Network and another name used for E-UTRAN is the Long Term Evolution (LTE) Radio Access Network (RAN). The core network where E-UTRAN is connected to is called Evolved Packet Core (EPC), a.k.a. System Architecture Evolution (SAE) network. Both the E-UTRAN and the EPC comprise together the Evolved Packet System (EPS) that is also known as the SAE/LTE network. A base station in LTE is called eNodeB or eNB (E-UTRAN NodeB). The specifications of LTE also include the possibility to have an E-UTRAN base station to provide home or small area coverage for a limited number of users. This base station is called HeNB (Home eNodeB) in this document. For UTRAN (WCDMA) this type of home access point is called HNB (Home NodeB). The LTE HeNBs are used to exemplify the home base stations in the examples below.
The HeNB would provide normal radio coverage for the end users and would be connected to the mobile core network using some kind of IP based transmission. The radio coverage provided is called femtocell in this document.
One of the main drivers of this new concept of providing Local Access is to provide cheaper call or transaction rates/charges when connected via the HeNB compared to when connected via the eNB. Another driver is reducing the load on the operator's eNBs and backhaul connections, thereby reducing the operator's capital and operating expenditures.
The HeNB would in most cases use the end user's already existing broadband connection (e.g. xDSL, Cable) to achieve connectivity to the operator's mobile core network and possibly to other eNBs/HeNBs. Over the broadband connection and other possible intermediate IP networks (e.g. the internet) a HeNB communicates with the core network nodes in the operator's network via an IPsec tunnel (Internet Protocol security architecture according to RFC 4301), which is established between the HeNB and a Security Gateway (SEGW), which protects the border of the operator's network.
FIG. 1 shows an exemplary LTE/SAE network with both femto 130 and macrocells 100 and their associated HeNBs 140 and eNBs 110. The HeNBs 140 are connected to the CN 170 via the HeNB Concentrator Node 160 also referred to as HeNB Gateway (HeNB GW) wherein the S1 interface 150 is used. Also, the eNBs 110 are connected to the CN 170 by using the S1 interface 120.
The main reasons for having a HeNB GW 160 between the HeNBs 140 and the CN 170 are due to the following three main issues:
1. The assumed number of HeNBs in a network is very high (millions of HeNBs is one estimate).
2. End users may switch on and off the HeNB frequently causing increased signaling load.
3. HeNBs may be tampered with (e.g. malicious/modified software).
The first issue creates a possible scaling problem on the core network (CN) side as each HeNB will have its own S1 interface towards the CN and it is assumed that the Mobility Management Entities (MMEs) of the CN are not capable of handling millions of S1 interfaces.
The second issue creates a possible signaling load problem on the CN side and this mostly in the MME due to HeNB S1 interfaces being frequently disconnected and reconnected.
The third issue creates a possible security problem in both the MME and Serving GW as any HeNB that is able to establish an IPsec tunnel to the SEGW (Security Gateway) of the operator's network may attack these nodes.
The HeNB GW is needed to solve these scaling, signaling load and security issues.
In the SAE/LTE 3GPP standards a concept known as CSG (Closed Subscriber Group) has been introduced (and it may also be introduced in the WCDMA/UTRAN 3GPP standard). With CSG, particular HeNBs can be associated to certain wireless terminals (also known as user equipments (UEs)) meaning that only these associated UEs are allowed to access the HeNBs. (A CSG is actually associated with a group of subscribers rather than UEs, but for simplicity the term UE will often be used as the entity of which a CSG is formed.) The allowed CSG Identities (CSG-ID) are stored in the UE in a so called CSG Whitelist. Each HeNB broadcasts in System Information (SI) both a “CSG Indicator” (Boolean type of indicator) and the CSG-ID allocated to it. This means that a UE can determine by reading the CSG-ID from the SI and comparing this to the contents of the CSG Whitelist whether it is allowed to access a particular HeNB. The allowed CSGs for a UE are also stored in the CN, so that the CN can perform an ultimate access control, e.g. in case a UE has an outdated CSG Whitelist or misbehaves (e.g. a hacked UE). One possible way to store the CSG Whitelist in the CN is to have it as part of the subscription/UE profile in the HSS (Home Subscriber Server). In this way it could be downloaded to the MME with the rest of the subscription information and the MME could perform the ultimate access control based on this information.
A new principle has been introduced for location registration in the SAE/LTE networks. This principle is based on a Tracking Area (TA) concept in a similar way as Location Areas (LA) and Routing Areas (RA) in GSM and WCDMA networks. Each SAE/LTE cell belongs normally to a single TA (if not considering RAN sharing deployments) and the Tracking Area Identity (TAI) is broadcasted as part of the SI. The current assumption is that the TAI will consist of a Mobile Country Code (MCC), a Mobile Network Code (MNC) and a Tracking Area Code (TAC).
The main difference from the LA/RA concepts is that in the TA concept of the SAE/LTE networks multiple TAs or a TAI List has been introduced. This means that the network may return a TAI List to the UE as part of some EMM (EPS Mobility Management) procedures like Attach, Tracking Area Update (TAU) and GUTI (Globally Unique Temporary Identity) Reallocation. As long as the UE camps on a cell belonging to a TA whose TAI is included in the TAI List, the UE does not perform normal TAUs (periodic TAUs are still performed). The UE performs normal TAU only when it moves to a cell that doesn't belong to a TA in the TAI List. As part of this TAU the UE will receive a new TAI List and the same procedure continues.
This principle is further shown in FIGS. 2a and 2b. FIG. 2a shows the case when the UE 200 has performed e.g. TAU and has received a TAI List of {TA1, TA2, TA3} from the CN. This means that the UE can move within TA1, TA2 and TA3 without performing TAU. In this document the notation TA1, TA2, etc. is used to denote both Tracking Area 1, Tracking Area 2, etc. and the TAIs of these Tracking Areas, depending on the context. For instance, when used to represent the TAI List, then TA1, TA2, etc. represent the TAIs in the list (i.e. the TAIs of Tracking Area 1, Tracking Area 2, etc.), whereas when it is stated that the UE can move freely within TA1, TA2, etc., then the terms TA1, TA2, etc. represent the actual Tracking Areas. The UE 200 in FIG. 2a is also moving towards the TA4 that is further described in FIG. 2b. 
In FIG. 2b, the UE 200 performs a TAU (as depicted using two arrows in FIG. 2b) when it moves to a cell belonging to TA4. After a successful TAU in TA4, the UE 200 receives TAI List {TA2, TA3, TA4} from the CN. Now the UE 200 can move within TA2, TA3 and TA4 without the need to perform a TAU.
One purpose with the TAU is to provide information about the UE location to the network. This information can then be used e.g. for paging purposes for mobile terminating transactions i.e. to locate the UE and to establish a signaling connection between the UE and the network. The main principle is that the network needs to page the UE in all the TAs represented by the whole TAI List i.e. in all the cells belonging to any of the TAs whose TAIs are included in the TAI List. For example, considering the scenario above in FIG. 2b, the network would need to page the UE in all cells belonging to TA2, TA3 or TA4.
There are different TA/TAI allocation mechanisms that can be used when femtocells are introduced to the SAE/LTE network. This is further shown in FIG. 3 where some femtocells 300 are shown being introduced in the geographical area covered by the TA1, TA2, TA3 and TA4 of the macrocells. The femtocells are installed by the end users themselves without any intervention from the mobile operator's personnel. This means that it is not really possible to perform cell or TA planning for femtocells as it is normally performed for macrocells. This leads to the assumed approach which is that each femtocell is allocated one TAI from a limited set of dedicated TAIs and that the TAIs need to be reused between different femtocells. These TAIs are not used in the macrocells. Each femtocell is allocated one of these TAIs during an automatic configuration procedure, normally when the HeNB is powered on. Typically a femtocell does not have any neighboring cells which share the same TAI.